WO 2005/027487 



1 



PCT/EP2004/052031 



Beschreibung 

Interworking von Protokollen hybrider Multimedianetze 

In der Vergangenheit haben sich zwei wesentliche Typen von 
Kommunikationsnetzen zur Ubermittlung von Inf ormationen her- 
ausgebildet: Paketorientierte (Daten-) Netze und leitungsori- 
entierte (Sprach-) Netze. Im Zuge der Konvergenz dieser bei- 
den Netztypen haben sich konvergente Multimedianetze heraus- 
gebildet. Duxch Zusairanenschluss dieser unterschiedlichen 
Netztypen entstehen hybride Netze. 

Leitungsorientierte Netze - auch Sprachnetze, Telephonnetze 
oder Public Switched Telephone Network (PSTN) genannt - sind 
auf die Ubermittlung von in der Fachwelt auch als (Sprech-) 
Verbindung, Gesprach oder Call bezeichneten kontinuierlich 
stromenden (Sprach-) Inf ormationen ausgelegt. Die Ubermitt- 
lung der Informationen erfolgt hierbei iiblicherweise mit 
hoher Dienstgute und Sicherheit. Beispielsweise ist fur Spra- 
che eine minimale - z.B. < 200 ms - Verzogerung (Delay) ohne 
Schwankungen der Verzogerungszeit (Delay- Jitter) wichtig, da, 
Sprache bei Wiedergabe im Empf angsgerat einen kontinuierli- 
chen Informationsf luss erfordert. Ein Inf ormationsverlust 
kann deshalb nicht durch ein nochmaliges Ubermitteln der 
nicht iibermittelten Information ausgeglichen werden und fuhrt 
im Empfangsgerat ublicherweise zu akustisch wahrnehmbaren 
Storungen (z.B. Knacksen, Verzerrung, Echo, Stille) . In der 
Fachwelt wird die Ubermittlung von Sprache verallgeme inert 
auch als Echtzeit- (Ubermittlungs-) Dienst bzw. als Realtime- 
Service bezeichnet. 

Paketorientierte Netze - auch Datennetze genannt - sind auf 
die Ubermittlung von in der Fachwelt auch als Datenpaketstro- 
me, Session oder Flow bezeichneten Paketstromen ausgelegt. 
Hierbei muss ublicherweise keine hohe Dienstgute garantiert 
werden. Ohne garantierte Dienstgute erfolgt die Ubermittlung 
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der Datenpaketstrome z.B. mit zeitlich schwankenden Verzo- 
gerungen, da die einzelnen Datenpakete der Datenpaketstrome 
ublicherweise in der Reihenfolge ihres Netzzugangs iibermit- 
telt werden, d.h. die zeitlichen Verzogerungen werden umso 
5 grower, je mehr Pakete von einem Datennetz zu iibermitteln 

sind. In der Fachwelt wird die Ubermittlung von Daten deshalb 
auch als Ubermittlungsdienst ohne Echtzeitbedingungen bzw. 
als Non-Realtime-Service bezeichnet. 

10 Die Pakete unterscheiden sich ublicherweise je nach Art des 
paketorientierten Netzes. Sie konnen beispielsweise als In- 
ternet, X.25 oder Frame Relay Pakete, aber auch als ATM Zel- 
len ausgebildet sein. Sie werden zuweilen auch als Nachrich- 
ten bezeichnet, v. a. dann, wenn eine Nachricht in einem Paket 

15 ubermittelt wird, 

Ein bekanntes Datennetz ist das Internet. Dieses wird wegen 
des dort zum Einsatz koxratienden Internet Protokoils IP zuwei- 
len auch IP Netz genannt, wobei dieser Begriff grundsatzlich 

20 weit zu verstehen ist und alle Netze umfasst, in denen das IP 
Protokoll eingesetzt wird. Das Internet ist als offenes 
(Weitverkehrs-) Datennetz mit offenen Schnittstellen zur 
Verbindung von (zumeist lokalen und regionalen) Datennetzen 
unterschiedlicher Hersteller konzipiert. Es stellt eine vom 

25 Hersteller unabhangige Transportplattf orm zur Verfugung. 

Verbindungen (Connections) sind Kommunikationsbeziehungen 
zwischen zumindest zwei Teilnehmern zum Zweck einer - zumeist 
gegenseitigen, d.h. bi-direktionalen - Inf ormationsubermitt- 

30 lung, Der die Verbindung initiierende Teilnehmer wird ubli- 
cherweise als "A-Teilnehmer 1 bezeichnet. Ein durch eine Ver- 
bindung mit einem A-Teilnehmer in Verbindung gesetzter Teil- 
nehmer heiftt 1 B- Teilnehmer 1 . In einem verbindungslosen Netz 
reprasentieren Verbindungen zumindest die auf logisch abs- 

35 trakter Ebene eindeutige Beziehung zwischen A- und B-Teil- 

nehmer, d.h. entsprechend dieser Sichtweise stellen z.B. die 
verbindungslosen Flows im Internet logisch abstrahierte Ver- 
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bindungen dar (z.B. A-Teilnehmer = Browser und B-Teilnehmer = 
Web Server) . In einem verbindungsorientierten Netz reprasen- 
tieren Verbindungen zudem auf physikalischer Ebene eindeutige 
Wege durch das Netz, entlang denen die Inf ormationen ubermit- 
5 telt werden. 

Signalisierung dient zur Abstimmung von Netzkomponenten un- 
tereinander, jedoch nicht zur "eigentlichen" Informations- 
ubermittlung im obigen Sinne. Die zur Signalisierung ubermit- 

10 telten Inf ormationen werden iiblicherweise als Signalisie- 
rungsinf ormationen , Signalisierungsdaten bzw. schlicht als 
Signalisierung bezeichnet. Der Begriff ist dabei weit zu 
verstehen. So sind z.B. auch die Nachrichten zur Steuerung 
von Registration, Admission und Status (RAS), die Nachrichten 

15 zur Steuerung von Nutzkanalen bestehender Gesprache (z.B. 

gemafl dem Standard H.245) sowie alle weiteren ahnlich ausge- 
bildeten Nachrichten umfasst. Die "eigentlichen Inf ormatio- 
nen" werden zur Onterscheidung von der Signalisierung auch 
Nutz inf ormationen, Payload, Medieninf ormationen, Mediendaten 

20 oder schlicht Medien genannt. Kommunikationsbeziehungen, die 
zur Ubermittlung der Signalisierung dienen, werden im weite- 
ren auch als Signalisierungsverbindungen bezeichnet. Die zur 
Ubermittlung der Nutzinf ormationen eingesetzten Kommunikati- 
onsbeziehungen werden z.B. Sprechverbindung, Nutzkanalverbin- 

25 dung oder - vereinfacht - Nutzkanal, Bearerchannel oder 
schlicht Bearer genannt. 

In diesem Zusammenhang versteht man unter out-of-band bzw. 

outband die Ubermittlung von Inf ormationen auf einem anderen 
30 Weg / Medium als den im Kommunikationsnetz zur Ubermittlung 

von Signalisierungs- und Nutzinf ormationen vorgesehenen. 

Insbesondere ist hiervon eine lokale Konf iguration von Ein- 

richtungen vor Ort umfasst, die z.B. mit einer lokalen Steu- 

ereinrichtung vorgenommen wird. Demgegenuber werden bei in- 
35 band Inf ormationen auf dem gleichen Weg / Medium, ggf . lo- 

gisch getrennt von den betrachteten Signalisierungs- und 
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Nutzinf ormationen, iibermittelt . 

Im Zuge der Konvergenz von Sprach- und Datennetzen werden 
Sprachiibermittlungsdienste und zunehmend auch breitbandigere 
Dienste wie z.B. Ubermittlung von Bewegtbildinf ormationen 
ebenfalls in paketorientierten Netzen realisiert, d.h. die 
Ubermittlung der bisher iiblicherweise leitungsorientiert 
iibermittelten Echtzeit dienste erfolgt in einem konvergenten 
Netz - auch Sprach-Daten-Netz oder Multimedianetz genannt - 
paketorientiert, d.h. in Paketstromen. Diese werden auch 
Echtzeitpaketstrome genannt. Die Ubermittlung von Sprachin- 
formationen iiber ein paketorientiertes IP Netz wird dabei 
auch mit 'VoIP' (Voice over IP) gekennzeichnet . 

In den internationalen Standardisierungsgremien IETF (Inter- 
net Engineering Task Force) und ITU (International Telecommu- 
nications Union) mehrere verteilte Architekturen fur Multime- 
dianetze beschrieben, die zunachst von homogenen Multimedia- 
netzen ausgehen. 

Bei der ITU wird im dazu grundlegenden Standard H.323 der 
Transport von Sprache, Daten und Videostromen iiber ein IP 
Netz definiert. Audio- und Videostrome werden dabei gemaJ3 
dem Protokoll RTP/RTCP iibermittelt. Die Connection Control 
wird u.a. durch das Protokoll H.225 bewirkt, das die Signa- 
lisierung, Registrierung und die Synchronisation von Me- 
dienstromen ermoglicht. Die H.323 Architektur sieht vor- 
nehmlich folgende Typen von Funktionseinheiten vor: 

- Endgerat, z.B. ein Terminal in einem Local Area Network 
(LAN) , zur bi-direktionalen Echtzeit-Kommunikation mit 
anderen Endgerat en, 

- Gatekeeper zur Durchfuhrung der Connection Control , 

- Media Gateway (MG) an der Schnittstelle zu anderen Netzen 
zur Konvertierung von H.323 Formaten in die Formate die- 
ser Netze, 

- Media Gateway Controller (MGC) zu Steuerung von Media 
Gateways, insbesondere deren jeweils iibermittelten Ver- 
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bindungen, mit Hilfe des Protokolls H.248 sowie zur Kon- 
vertierung zwischen unterschiedlichen Signalisierungspro- 
tokollen. 

5 Bei der IETF wird im Session Initiation Protocoll (SIP) die 
Telephonie iiber das Internet genormt, womit interaktive 
Verbindungen iiber das Internet bereitgestellt werden kon- 
nen. SIP unterstiitzt die Steuerung von Verbindungen und die 
Ubersetzung von SIP Adressen in IP Adressen. SIP basiert 

10 auf vergleichsweise intelligenten Endpunkten, von denen 
viele SignaJLisierungsfunktion selbst durchgef iihrt . Wenn 
eine Connection mit Hilfe von SIP aufgebaut wird, so wird 
zwischen den beiden Seiten der Verbindung ublicherweise eine 
Beschreibung des Bearers ausgetauscht . Dazu wird das Session 

15 Description Protocol (SDP) nach dem Standard RFC2327 einge- 
setzt. Dieser Einsatz ist u.a. im Standard RFC3264: "An Of- 
fer/Answer Model with the Session Description Protocol (SDP) " 
beschrieben. Wichtig sind dabei vor allem folgende Bearer 
Daten: 

20 

- IP Adresse der Bearer Connection 

- RTP/UDP Port der Bearer Connection (je nachdem, ob eine 
Sprach- oder Datenubertragung vorliegt) 

- Codec (s), die fur die Sprach bzw. Datenubertragung beniitzt 
25 werden (konnen) 

- Strearnmode der Bearer Connection 

Bei einem Connection Setup kann ein SIP Proxy Server zum 
Einsatz kommen, z.B. wenn sich die in Verbindung stehenden 

30 Endpunkte nicht kennen. Er kann auch dafiir ausgelegt sein, 
einen empfangenen Request fur einen Client (z.B. ein IP 
Telefon, einen PC oder ein PDA) zu bewerten, zu andern 
und/oder weiterzugeben. An der Schnittstelle zu anderen 
Netzen sind ebenfalls MG und MGC vorgesehen. Zur Steuerung 

35 der MG wird das Protokoll MGCP (Media Gateway Control Pro- 
tokoll) genutzt. 
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Beiden Architekturen ist gemeinsam, dass die Connection 
Control Ebene und die Resource Control Ebene funktional deut- 
lich voneinander getrennt sind und meist sogar auf unter- 
schiedlichen Hardware Plattformen realisiert werden. 

Die Connection Control Ebene dient der geregelten Aktivierung 
und Deaktivierung von Netzdiensten. Sie kann dazu dedizierte 
Connection Controller umfassen, denen folgende Funktionen 
zugeordnet sein konnen: 
10 - Address Translation: Umsetzung von E.164 Telephonnummern 
und anderen Alias Adressen (z.B. Rechnernamen) auf Trans- 
portadressen (z.B. Internetadressen) . 

- Admission Control: Priifung, ob und/oder in welchem Umfang 
eine Nutzung des Kommunikationsnetzes zulassig ist. 

15 - Alias Address Modification: Riickgabe einer modif izierten 

Alias Adresse, die von Endpunkten z.B. zum Verbindungsauf- 
bau verwendet werden. 

- Bandwidth Control: Verwaltung von Ubermittlungskapazita- 
ten, z.B. durch Steuerung der zulassigen Anzahl von Ein- 

20 richtungen, die gleichzeitig das Kommunikat ions net z nutzen 

durfen. 

- Connection Authorization: Zulassigkeitspruf ung fur einge- 
hende und ausgehende Verbindungswunsche . 

- Connection Control Signalling: Vermittlung und/oder Verar- 
25 beitung von Signalisierungsnachrichten . 

- Connection Management: Verwaltung von bestehenden Verbin- 
dungen . 

- Dialed Digit Translation: Ubersetzung der gewahlten Zif- 
fern in eine E.164 Telephonnummer oder eine Nummer aus ei- 

30 nem privaten Nummer ierungs schema. 

- Zone Management: Registrierung von (z.B. VoIP fahigen) 
Einrichtungen und Bereitstellung obiger Funktionen fur al- 
le beim Connection Controller iregistrierten Einrichtungen. 

35 Die Resource Control Ebene dient der geregelten Durchfiihrung 
aktivierter Dienste. Zur Steuerung der Netzressourcen (z.B. 
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Ubermi tt lungs kno ten) kann sie Resource Controller umfassen, 
denen folgende Funktionen zugeordnet sein konnen: 

- Capacity Control: Steuerung des dem Kommunikationsnetz 
zugefiihrten Verkehrsvolumens, z.B. durch Kontrolle und 
ggf • Begrenzung der zulassigen Ubermittlungskapazitat ein- 
zelner Paketstrome . 

- Policy Activation: Reservierung von <Ubermittlungs-) Res- 
sourcen im Kommunikationsnetz. 

- Priority Management: Bevorzugte Ubermi ttlung von prioren 
Verkehrsstromen, z.B. mit Hilfe von Prioritatskennzeichen, 
die in prioren Paketen vorgesehen werden. 

Beispiele fur Connection Controller stellen der von der ITU 
in der H.323 Gatekeeper oder der SIP Proxy dar. Wird ein 
groBeres Kommunikationsnetz in mehrere Domanen - auch 'Zonen 1 
genannt - gegliedert, kann in jeder Domane ein separater 
Connection Controller vorgesehen werden. Eine Domane kann 
auch ohne einen Connection Controller betrieben werden. Sind 
mehrere Connection Controller in einer Domane vorgesehen, 
soli nur ein einziger von diesen aktiviert sein. Ein Connec- 
tion Controller ist aus logischer Sicht getrennt von den 
Einrichtungen zu sehen. Physikalisch muss er jedoch nicht in 
einer separaten Connection Controller Einrichtung realisiert 
sein, sondern kann auch in jedem Endpunkt einer Verbindung 
(beispielsweise ausgebildet als H.323 oder SIP Endgerat, 
Media Gateway, Multipoint Control Unit) oder auch einer pri- 
mar zur programmgesteuerten Datenverarbeitung ausgebildeten 
Einrichtung (beispielsweise: Rechner, PC, Server) vorgesehen 
werden. Auch eine physikalisch verteilte Realisierung ist 
moglich. 

Ein alternatives Beispiel fur einen Connection Controller ist 
ein Media Gateway Controller, dem ublicherweise die optiona- 
len Funktionen Connection Control Signalling and Connection 
Management zugeordnet werden. Weiterhin ist die Zuordnung 
einer Funktion Signalling Conversion zur Umsetzung unter- 
schiedlicher (Signalisierung-) Protokolle denkbar, was z.B. 
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an der Grenze von zwei unterschiedlichen Netzen, die zu einem 
hybriden Netz zusammengeschlossen sind, erforderlich sein 
kann . 

5 Der Resource Controller wird auch als 'Policy Decision Point 
(PDP) ■ bezeichnet. Er ist beispielsweise innerhalb von sog. 
Edge Routern - auch Edge Device , Zugangsknoten oder bei Zu- 
ordnung zu einem Internet Service Provider (ISP) auch Provi- 
der Edge Router (PER) genannt - realisiert. Diese Edge Router 

10 kdnnen auch als Media Gateway zu anderen Netzen ausgebildet 
sein, mit denen die Multimedianetze verbunden werden. Diese 
Media Gateway sind dann sowohl mit einem Multimedianetz als 
mit den anderen Netzen verbunden und dienen intern der Umset- 
zung zwischen den unterschiedlichen (Ubermitt lungs-) Proto- 

15 kollen der verschiedenen Netze. Der Resource Controller kann 
auch nur als Proxy ausgebildet sein und Resource Controller 
relevante Inf ormationen an eine separate Einrichtung weiter- 
leiten, auf der die relevanten Inf ormationen entsprechend 
einer Funktion des Resource Controllers bearbeitet werden. 

20 

Der Austausch von Signalisierungsnachrichten erfolgt in die- 
sen Netzen entweder unter Vermittlung eines Connection Cont- 
rollers (Connection Controller Routed Signalling - CCRS) oder 
direkt zwischen den Endgeraten (Direct Endpoint Routed 
25 Signalling - DERS) . Es kann je Connection fur jedes Endgerat 
und fur jede Ubertragungsrichtung individuell festgelegt 
werden, welche Variante zum Einsatz kommt. 

Beim CCRS werden alle Signalisierungsnachrichten von zurnin- 
30 dest einem Call Controller iibermittelt. Alle Einrichtungen 

schicken und erhalten Signalisierungsnachrichten nur iiber den 
Call Controller. Ein direkter Austausch von Signalisierungs- 
nachrichten zwischen den Einrichtungen ist dabei untersagt . 

35 Beim DERS konnen Kopien ausgewahlter Signalisierungsnachrich- 
ten an Connection Controller iibermittelt werden, so dass ein 
Connection Controller auch bei dieser Variante Kenntnis von 
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den zwischen den Endgeraten bestehenden Verbindungen haben 
kann. Diese Verbindungen werden jedoch von ihm selbst nicht 
aktiv beeinflusst Oder verifiziert. 

Zusammenf assend kann der Function Split zwischen den beiden 
Ebenen so beschrieben werden, dass der Resource Control Ebene 
lediglich die Funktionen zugeordnet sind, die zur Ubermitt- 
lung von Nutzinf ormationen erforderlich sind, wahrend von der 
Connection Control Ebene die Intelligenz zur Steuerung der 
Resource Control Ebene umfasst ist. Mit anderen Worten: Die 
Einrichtungen der Resource Control Ebene besitzen moglichst 
wenig Netzsteuerungsintelligenz und konnen in der Folge wirt- 
schaftlich besonders vorteilhaft auf separaten Hardware 
Plattformen realisiert werden. Dies ist wegen der im Ver- 
gleich zu Connection Control Ebene hoheren Installationszah- 
len in dieser Ebene ein besonders schoner Vorteil. 

Durch Zusammenschluss von unterschiedlichen Netzen entstehen 
hybride Netze, in denen unterschiedliche Protokolle zum Ein- 
satz koiranen. Damit im einem derartigen Netz alle Gerate un- 
eingeschrankt miteinander komrnunizieren konnen (z.B. IP ba- 
sierte Telephone mit PSTN kompatiblen und umgekehrt) , ist 
ein Interworking zwischen den jeweiligen Protokollen (z.B. 
SIP und H.323 in paketorientierten Multimedianetzen bzw. 
ISUP und DSS1 in leitungsorientierten PSTN Netzen) erfor- 
derlich. Dieses Interworking ist weit zu versetzen und 
umfasst neben dem reinen Interworking der Bearer auch das 
Interworking von Leistungsmerkmalen bzw. Services wie Call 
Hold, Call Waiting (Anklopfen) , Call , Redirect (Rufweiter- 
leitung) , 3PTY (Drei-Parteien-Konf erenz - auch ' kleine 
Konf erenz ' genannt ~, siehe ITU-T Standard Q.734.2) oder 
CONF (Konferenz ohne mengenmaflige Beschrankung der Konfe- 
renzteilnehitier - auch 'grofle Konferenz' genannt siehe 
ITU-T Standard Q. 734.1). 

Das Interworking zwischen zwei unterschiedlichen Protokol- 
len kann mittelbar oder unmittelbar bewirkt werden. Beim 
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mittelbaren Interworking ward ein weiteres, drittes Proto- 
koll zwischen die beiden Protokolle geschaltet - z.B. das 
Protokoll BICC (Bearer Independent Call Control) gemaB dem 
Standard Q.1902 oder das Protokoll SIP_T (SIP for Telepho- 
nes), das im Standard RFC3372 beschrieben ist . Das unmittel- 
bare Interworking erfolgt hingegen direkt zwischen den 
beiden unterschiedlichen Protokollen, d.h. ohne Einsatz 
eines »Zwischenprotokolls . 

Sowohl in konvergenten Multimedianetzen als auch in hybriden 
Netzen, die z.B. durch einen Zusaimtienschluss eines konvergen- 
ten Multimedianetzes mit einem konventionellen leitungsorien- 
tierten Sprachnetz gebildet werden, entstehen bei der Uber- 
mittlung von Inf ormationen - insbesondere der in Echtzeitpa- 
ketstromen - neue technische Problemstellungen aufgrund der 
neuen bzw. unterschiedlichen Technologies die in den jewei- 
ligen Netztypen zum Einsatz kommen. 

Es ist Aufgabe der Erfindung, zuraindest eines dieser Probleme 
zu erkennen und durch Angabe von zumindest einer Losung den 
Stand der Technik zu bereichern. 

Die Erfindung geht von der Erkenntnis aus, dass wahrend der 
Evolution von hybriden Netzen, die durch die Zusammenschal- 
tung von bewahrten leitungsorientierten Netzen mit modernen 
Multimedianetzen entstehen, viele der in den leitungsorien- 
tierten Netzen seit langem etablierten Leistungsmerkmale 
nicht Oder zumindest nicht vollstandig unterstutzt werden. 
Eine Ursache hierfiir wird in der groBen Anzahl von neuen 
Interworking Schnittstellen und Protokollen gesehen, von 
denen die bisherigen Leistungsmerkmale noch nicht bzw. nicht 
vollstandig unterstutzt werden. 

Weiterhin wird die Erfindung von der Erkenntnis getragen, 
dass die dif f erenzierten Vorgaben zum Bearer Handling in PSTN 
Netzen und in SIP Netzen nicht zueinander passen. Wahrend in 
PSTN Netzen dem Partner signalisiert wird, dass die eigene 
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Senderichtung blockiert ist, muii in SIP Netzen dem Partner 
signalisiert werden, dass dieser die (aus Sicht des Signali- 
sierenden) remote Senderichtung zu unterbrechen hat, da in 
SIP Netzen lediglich die eigene Senderichtung, ' nicht aber die 
5 eigene Empfangsrichtung aufgetrennt wird. Mit anderen Worten: 
In SIP Netzen unterdriickt jeder SIP Teilnehmer seine eigene 
Senderichtung selbst durch Deaktivierung seines Senders (sie- 
he IETF Standard RFC3264, Kap. 8.4). 

10 Diese Diskrepanz wird noch vertieft, indem im IETF Standard 
RFC3264 (offer/answer) fur SIP generell das Wegschalten des 
Bearers bei holding conditions gefordert wird, was zu einer 
Reduzierung der erf orderlichen Bandbreite in SIP Netzen fuh- 
ren soil. Diese Forderung erstreckt sich auch auf hybride 

15 Netze, die sich durch Zusammenschaltung von SIP Netzen und 
PSTN Netzen ergeben, und zwar auch dann, wenn zur Durchfuh- 
rung eines Leistungsmerkmals eigentlich gar kein Wegschalten 
des Bearers im SIP Netz mehr erforderlich ware, weil im PSTN 
Netz bereits alle erforderlichen Schritte zur erf olgreichen 

20 Durchfuhrung des Leistungsmerkmals bewirkt worden sind. So 

kann bei Aufbau einer Konferenz im PSTN Netz eine Verbindung 
zu einem SIP Teilnehmer problemfrei auf Hold geschaltet wer- 
den, weil die zugeordnete Vermittlungsstelle in diesem Fall 
die Verbindung zwischen den beiden Teilnehmern zentral in 

25 beiden Ubermittlungsrichtungen unterbrechen wird. In diesem 
Fall werden vom SIP Teilnehmer empfangene Inf ormationen in 
dieser Vermittlungsstelle verworfen, was fur den angestrebten 
Aufbau einer Konferenz soweit schadlos ist. Dennoch wurde im 
ITU-T Draft-Standard Q. 1912. SIP ein Interworking der Proto- 

30 kolle BICC / ISUP auf das SIP-Protokoll genormt, wie die 
BICC / ISUP Indikationen fur "remote hold" und "remote 
retrieve" auf ein SIP-Protokoll zu mappen sind. 

Der Erfindung liegt die Erkenntnis zu Grunde, dass die Indi- 
35 katoren "remote hold" und "remote retrieve" nicht nur wahrend 
der Durchfuhrung des Leistungsmerkmals HOLD zum Einsatz kom- 
men, sondern auch bei der Durchfuhrung der Leistungsmerkmale 
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3PTY und CONF. Dies hat zur Folge, dass mit dem Aufbau einer 
Konferenz wegen der dabei eingesetzten Indikatoren "remote 
hold" zusatzlich zu der zentrale Unterbrechung der Verbindun- 
gen im PSTN Netz eine Deaktivierung der SIP-seitigen Sender 
5 einher geht. 

Diese Deaktivierung kann in dem Interworking Szenario dieses 
hybriden Netzes nicht mehr aufgelost werden, denn im ein- 
schl&gigen Interworking Draft-Standard Q. 1912, SIP der ITU-T 
10 ist dieses Problem weder angesprochen, noch findet sich ir- 
gendein Hinweis auf dessen Losung. 

Eine Losung fur diese der Erfindung zugrunde liegende Prob- 
lemsituation ist in den Patentanspriichen angegeben. 

15 

Mit dieser Losung sind eine Vielzahl von Vorteilen verbunden: 

- Im Zuge der Konf iguration von Verbindungen gemaB dem ers- 
ten Protokoll werden im leitungsorientierten Netz gene- 

20 rierte Meldungen dann auf Nachrichten des zweiten Proto- 

kolls im Multimedianetz abgebildet, wenn dort zuvor eine 
dezentrale Unterbrechung der Verbindungen durch Deaktivie- 
rung der uni-direktionalen Sender am Ende der Verbindungen 
bewirkt wurde und die Art der Konf iguration eine Aktivie- 

25 ' rung der Sender erforderlich macht. Damit wird ein Verfah- 
ren angeboten, welches es dem Operator ermoglicht, die 
Features 3PTY und CONF auch in einem hybriden ISUP / 
BICC / H323 Netz mit Interworking zu SIP anzubieten. 

30 - Durch parallele Auftrennung von Nutzkanaien, zunachst 

gemaft dem ersten Protokoll durch zentrale Unterbrechung in 
einem zentralen Obermittlungsknoten des leitungsorientier- 
ten Netzes und dann im Zuge des Interworkings auf das 
zweite Protokoll durch Deaktivierung der Sender im Multi- 

35 medianetz wird eine optimale Lastreduzierung im hybriden 
Netz erreicht. Vorteilhaft konnen die bewahrte Konferenz- 
Leistungsmerkmale 3PTY und CONF von leitungsorientierten 
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Netzen auch bei Interworking mit Multimedianetzen so 
durchgefiihrt werden, dass in den Multimedianetzen keine 
Nutzinformationen iibermittelt werden, solange eine Verbin- 
dung von einer Konferenz isoliert ist. 

5 

Weitere vorteilhafte Ausgestaltungen der Erfindung ergeben 
sich aus den unter- oder nebengeordneten Anspriichen. 

Mit der Angabe einer detaillierten Mapping Vorschrift von 
10 Q.734 Nachrichten auf SIP Nachrichten ist der scheme Vorteil 
verbunden, dass die Weiterentwicklung des Draft-Standards 
Q. 1912. SIP (Stand 07/2003) erheblich erleichtert wird. 

Durch die zustandsabhangige Ausbildung der SIP Nachrichten 
15 entweder als INVITE oder als UPDATE wird vorteilhaft die 
Empfehlung des IETF Standards RFC3311, Kap. 5.1 erfullt, 
wonach einerseits ein nochmaliges Senden einer INVITE im 
Zustand "before answer" nicht erlaubt ist, weil dies zu Ab- 
grenzungsschwierigkeiten mit der urspriinglichen INVITE fiihren 
20 kann, wahrend andererseits nach der Answer "200 OK" (dort 
"confirmed dialogue" genannt) zwar grundsatzlich ebenfalls 
ein UPDATE gesendet werden konnte, das nochmalige Senden 
einer INVITE (auch "re- INVITE" genannt) aber empfohlen wird. 

25 Die Erfindung wird im folgenden anhand von weiteren Ausfiih- 
rungsbeispielen, die auch in den Figuren dargestellt sind, 
erlautert. Dabei zeigt: 

Figur 1 eine exemplarische Anordnung zur Durchfiihrung des 
30 erfindungsgemaflen Verfahrens mit einem hybriden Kom- 

munikationsnetz, bestehend aus zwei paketorientier- 
ten Multimedianetzen und einem leitungsorientierten 
Sprachnetz, die durch zwischengeschaltete Media Ga- 
teway, Media Gateway Controller und SIP Proxies ver- 
35 bunden sind, sowie je einem Endpunkt eines gemeinsa- 

men Leistungsmerkmals in jedem der drei Netze 
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Figur 2 ein Ablaufdiagramm, in dem eine Ausfuhrung der Er- 
findung exemplarisch aufgezeigt ist 

In Figur 1 ist eine beispielhafte Anordnung zur Durchfiihrung 
5 des erfindungsgemaJften Verfahrens dargestellt. Sie umfasst ein 
leitungsorientiertes Netz PSTN A und zwei Multimedianetze IN B 
und IN C , die vorzugsweise als integrierte Sprach-Daten-Netze 
SDN ausgebildet sind. Die Netze PSTN Af IN B und IN C sind zu 
einem hybriden Netz zusammengeschlossen. Die Netze IN sind 

10 vorzugsweise als IP Netze ausgebildet und umfassen als Call 
Controller je einen SIP Proxy SP B bzw. SP C - Fur den einschla- 
gigen Fachmann ist dabei of f ensichtlich, dass die Erfindung 
selbstverstandlich in beliebigen paketorientierten Net zen IN 
zum Einsatz kommen kann wie z.B. Internet, Intranet, Extra- 

15 net, einem lokalen Netz (Local Area Network - LAN) oder ei- . 
nem, z.B. als Virtuelles Privates Netz (VPN) ausgebildeten 
f irmeninternen Netz (Corporate Network) . 

An das Netz PSTN a ist ein Teilnehmer A mit Hilfe eines her- 
20 kommlichen Telephons T, an die Netze IN B und IN C sind Teil- 
nehmer B und C mit Hilfe von SIP fahigen Telephonen - z.B. in 
Software realisierten SIP Clients SC - angeschlossen. Zwi- 
schen dem Teilnehmer A und B ist eine Verbindung vorgesehen, 
die als Bearer einen end-to-end Nutzkanal TDM A / B , RTP/RTCP A / B 
25 umfasst. Zudem ist zwischen dem Teilnehmer A und C eine wei- 
tere Verbindung vorgesehen, die als Bearer einen end-to-end 
Nutzkanal TDM A / C , RTP/RTCP A / C umfasst. Dem Teilnehmer A ist 
eine leitungsorientierte Vermittlungseinrichtung LE A zugeord- 
net, umfassend eine Steuerung fur Leistungsmerkmale 3PTY bzw. 
30 CONF, mit denen die Verbindungen im Rahmen der Leistungsmerk- 
male konf iguriert, insbesondere im Rahmen einer Konferenz 
miteinander verbunden und voneinander isoliert werden konnen. 

Der Zusammenschluss der leitungsorientierten Bearer TDM mit 
35 den paketorientierten Bearern RTP/RTCP wird durch ein zwi- 

schengeschaltetes Media Gateway MG zur Konvertierung zwischen 
unterschiedlichen, netzspezif ischen Nutzkanaltechnologien 
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RTP/RTCP (Real Time [Control] Protocol) und TDM (Time Devisi- 
on Multiplex) , der Zusammenschluss der Signalisierung SS7 des 
Netzes PSTN mit der Signalisierung SIP der Netze IN durch 
zwischengeschaltete Media Gateway Controller MGC A / B und MGC C 
5 bewirkt. Dabei wird vom Controller MGC A / B ein unmittelbares 
Interworking zwischen den unterschiedlichen netzspezif ischen 
Signalisierungsprotokollen ISUP des Netzes PSTN und SIP B des 
Netzes IN B bewirkt. Zwischen den Controllern MGC A / B und MGC C 
kommt hingegen ein Protokoll BICC oder SIP_T zum mittelbaren 
10 Interworking zwischen den unterschiedlichen Signalisierungs- 
protokollen ISUP des Netzes PSTN und SIP C des Netzes IN C zum 
Einsatz . 

Das Gateway MG wird von dem ihm zugeordneten Controller MGC A / B 
15 durch ein - vorzugsweise international genormtes - Protokoll, 
z.B. MGCP (Media Gateway Control Protocol) oder H.248 gesteu- 
ert. Es ist iiblicherweise als separate Einheit realisiert, 
die auf einer anderen physikalischen Einrichtung / Hardware 
Plattform zum Ablauf kommt als der ihm zugeordnete Controller 
20 MGC A/B . 

In Figur 2 ist die Abfolge von ersten ISUP Nachrichten zum 
Aufbau der Verbindung CALL A/B zwischen den Teilnehmern A und B 
sowie die Abfolge von zweiten ISUP Nachrichten zur Erweite- 

25 rung der Verbindung CALL A/B zu einer Konferenz mit einer dazu 
aufgebauten weiteren Verbindung CALL A/C zwischen den Teilneh- 
mern A und C dargestellt. Weiterhin ist das Interworking der 
ersten ISUP Nachrichten auf das Protokoll SIP B sowie das 
erfindungsgemafie Interworking der zweiten Nachrichten auf die 

30 Protokolle SIP B und SIP C aufgezeigt. 

Es sei betont, dass die derart aufgezeigten Ausfuhrungen der 
Erfindung trotz ihrer teilweise sehr detailgetreuen Darstel- 
lung von konkreten Netzszenarien lediglich beispielhaf ter 
35 Natur und nicht einschrankend zu verstehen sind. Dem Fachmann 
ist klar, dass die Erfindung bei alien denkbaren Netzkonfigu- 
rationen, insbesondere anderen Interworking Szenarien funkti- 
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oniert. Insbesondere konnen die Protokolle SIP durch Proto- 
koll der H.323 Familie oder andere wirkungsgleiche Protokolle 
ersetzt werden. 

5 Im folgenden wird ein Ausfiihrungsbeispiel der Erfindung er- 
lautert, bei dem der PSTN Teilnehmer A als Leistungsmerkmal 
eine kleine Konferenz 3PTY mit den SIP Teilnehmern B und C 
aufbaut. Dieses Beispiel ist auch in Figur 2 dargestellt. 

10 Zunachst wird in iiblicher Weise ein Verbindung CALL A/B zwi- 

schen den Teilnehmern A und B aufgebaut, wobei in Figur 2 die 
Initiative von dem SIP Teilnehmer B ausgeht, allerdings auch 
ohne Einschrankung von dem PSTN Teilnehmer A ausgehen konnte. 
Dabei wird die SIP Signalisierung SIP: Invite (SDP B ) beim 

15 Interworking zwischen dem ersten Protokoll ISUP und dem zwei- 
ten Protokoll SIP in iiblicher Weise auf die ISUP Signalisie- 
rung 0:1AM gemappt. Ebenso werden die ISUP Signalisierungen 
0:ACM und O : ANM, mit denen das Klingeln des Telephons T und 
die Annahme des Gesprachs durch den Teilnehmer A angezeigt 

20 werden, in iiblicher Weise auf die SIP Nachrichten 180: Ringing 
und 200 :OK (SDP mgc _b) abgebildet. Nach Aufbau umfasst die 
Verbindung CALL A / B zumindest einen (bei einem Telephongespr&ch 
iiblicherweise bi-direktionalen) Nutzkanal TDM A / B , RTP/RTCP A / B 
zur Ubermittlung von Inf ormationen zwischen den Teilnehmern A 

25 und B. Dieser Kanal ist in Figur 1 dargestellt. 

Im weiteren Verlauf soli nun das bestehende Gesprach CALL A / B 
auf eine Konferenz 3PTY mit dem Teilnehmer C erweitert wer- 
den. Die Initiative geht dabei von dem PSTN Teilnehmer A aus. 

30 Dazu wird zunachst die Verbindung CALL A/B durch Aussenden der 
ISUP Nachricht 0:CPG (RemoteHold) auf HOLD gelegt. Als Folge 
wird zum einen der Nutzkanal TDM A / B , RTP/RTCP A/B in der Ver- 
mittlungsstelle LE A zentral in beide Obermittlungsrichtungen 
unterbrochen (siehe Figur 1) . Zudem wird bei Teilnehmer B die 

35 Senderichtung des SIP Clients SC durch Senden einer SIP Nach- 
richt SIP: Invite mit IP Adresse des Controllers MGC B = 
0.0.0.0 deaktiviert (siehe Figur 2). Das dazu erforderlich 
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Interworking ist im Draft-Standard Q. 1912. SIP definiert. Die 
Deaktivierung kann alternativ auch durch Senden einer SIP 
Nachricht SIP: Invite mit einer Attributzeile " a=sendonly" 
oder "a=inactive" bewirkt werden (in Figur 2 nicht darge- 
5 stellt) . Durch die Berucksichtigung von 3PTY und CONF wird 
also an dem bisherigen Verfahren fur das Leistungsmerkmal 
CALL HOLD nichts geandert. 

Anschlieliend wird vom Teilnehmer A eine Verbindung CALL A /c zum 
10 Teilnehmer C in iiblicher Weise aufgebaut. Im Beispiel ist 
dabei ein beschleunigter Verbindungsaufbau dargestellt, bei 
dem die ISUP Nachrichten OrACM und O: ANM durch eine einzige 
ISUP Nachricht O:C0N (= "connected") ersetzt sind. Dies hat 
auf die Erfindung keine Auswirkung. Nach Aufbau umfasst die 
15 Verbindung CALL A/C zumindest einen Nutzkanal TDM A/C , RTP/RTCP A/C 
zur Ubermittlung von Informationen zwischen den Teilnehmern A 
und C. Dieser Kanal ist in Figur 1 dargestellt. 

Nach Aufbau der Verbindung CALL A/C wird von Teilnehmer A die 
20 Zusammenschaltung der beiden Verbindungen CALL A / B und CALL A/C 
zu einer (kleinen) Konferenz 3PTY initiiert. Diese Zusammen- 
schaltung wird in iiblicher Weise von der Vermittlungsstelle 
LE A des Netzes PSTN bewirkt (siehe Figur 1) - Insbesondere 
werden die beiden Nutzkanale TDM A/B , RTP/RTCP A/B und TDM A/C/ 
25 RTP/RTCP A / C dort so miteinander verbunden, dass sich alle drei 
Teilnehmer gegenseitig horen konnen. Diese Konfiguration der 
Verbindungen CALL wird den betroffenen Teilnehmern B und C 
mit Hilfe von zwei dediziert an sie gerichteten ISUP Nach- 
richten 0:CPG (ConferenceEstablished) mitgeteilt, d.h. diese 
30 Nachricht wird zu beiden Teilnehmern B, C gesendet. 

Infolge der Deaktivierung des Teilnehmers B ist dieser jedoch 
trotz der Zusammenschaltung der Nutzkanale weiterhin von der 
Konferenz 3PTY abgeschnitten. Dies gilt nicht fur den Teil- 
35 nehmer C, da dieser nicht deaktiviert wurde. Erf indungsgemafl 
wird deshalb auf die beiden Nachrichten 0:CPG (Conferen- 
ceEstablished) differenziert reagiert, indem in Hinblick auf 
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den Teilnehmer B ein Interworking durchgefuhrt wird und in 
Hinblick auf den Teilnehmer C darauf verzichtet wird. Das 
Interworking zu Teinehmer B wird dabei so ausgestaltet, dass 
die Senderichtung des SIP Clients SC durch Senden einer SIP 
5 Nachricht SIP:Invite (SDP M gc_b) , d.h. niit Angabe der IP Adres- 
se des Controllers MGC B wieder aktiviert (siehe Figur 2) . Die 
Aktivierung kann alternativ auch durch Senden einer SIP Nach- 
richt SIP: Invite mit einer Attributzeile "a=sendrecv" oder 
"a=recvonly" bewirkt werden (in Figur 2 nicht dargestellt) , 

10 je nachdem, ob der Teilnehmer B vor seiner Deaktivierung 

Informationen bi-direktional Oder uni-direktional ubermittelt 
hat, oder auch durch Senden einer SIP Nachricht SIP: Invite 
ohne diese Attributzeile. Nach Durchfuhrung des Interworkings 
kann auch der Teilnehmer B in der Konferenz 3PTY gehort wer- 

15 den. 

Als besonders vorteilhafte Variante wird auch auf dieses 
Interworking verzichtet, wenn der Teilnehmer B bereits vor 
Empfang der ISUP Nachricht 0:CPG (ConferenceEstablished) 
20 wieder aktiviert worden ist. Dazu wird der Status des Teil- 
nehmers B vor dem Interworking uberpruf't. Im Status "held" 
muJi eine SIP Nachricht SIP: gesendet werden, ansonsten nicht. 

Dieses Mapping gilt sinngemaJi auch fur die ISUP Nachrichten 
25 mit den Generic Notification Indicator Parametern "Conference 
disconnected", "Isolated" und "Reattached". Bei "conference 
disconnected" mufl ebenfalls uberpruft werden, in welchem 
Status sich der SIP Teilnehmer befindet: im Status "held" 
wird die SIP Nachricht SIP: Invite mit der realen IP Adresse 
30 und / oder der Attributzeile "a=sendrecv" gesendet. Fur das 
Leitungsmerkmal CONF sind zusatzlich der Wert "Isolated" in 
eine SIP Nachricht Invite mit IP Adresse = 0.0.0.0 und / oder 
die Attributzeile "a=sendonly" und der Wert "Reattached" in 
eine SIP Nachricht SIP: Invite mit der realen IP Adresse und / 
35 oder der Attributzeile "a=sendrecv" zu mappen. 
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Zusammengefasst wird zur Unterstiitzung der Features CONF 
(Conference) und 3PTY (Three Parties) erf indungsgemafi folgen- 
de Mindesterweiterung des ITU-T Draft-Standard Q. 1912. SIP 
vorgeschlagen : 











Answered 


CPG with 

" Conference established " 




INVITE with the attribute line "a=sendrecv", or 
omitted attribute line, or "a= recvonly" for the 
offered media stream 

in case re-INVITE with "hold" (corresponding to 
"a=sendonly" or "a=inactive") had already been 
send and no re-INVITE with "no hold" (corre- 
sponding to "a=sendrecv", or omitted attribute 
line ) had been sent in the meanwhile . 

otherwise no mapping 


Answered 


CPG with 

" Conference disconnected 


=> 


INVITE with the attribute line "a=sendrecv", or 
omitted attribute line, or "a= recvonly'Vfor the . 
offered media stream 

in case re-INVITE with "hold" (corresponding to 
"a=sendonly" or "a=inactive") had already been 
send and no re-INVITE with "no hold" (corre- 
sponding to "a=sendrecv", or omitted attribute 
line ) had been sent in the meanwhile . 

otherwise no mapping 


Answered 


CPG with " Isolated " 




INVITE with the attribute line "a=sendonly" or 
"a=inactive" for the offered media stream 


Answered 


CPG with " Reattached " 


==> 


INVITE with the attribute line "a=sendrecv", or 
omitted attribute line, or "a= recvonly" for the 
offered media stream 


before 
answer 


CPG with 

11 Conference established " 




UPDATE with the attribute line "a=sendonly" or 
"a=inactive" for the offered media stream 

in case UPDATE with "hold" had already been 
send ana no UrDA I b with no noia naa oeen 
sent in the meanwhile . 

otherwise no mapping 


before 
answer 


CPG with 

"Conference disconnected " 




UPDATE with the attribute line "a=sendrecv", or 
omitted attribute line, or "a= recvonly" for the 
offered media stream 

in case UPDTAE with "hold" had already been 
send and no UPDATE with "no hold" had been 
sent in the meanwhile . 

otherwise no mapping 


before 
answer 


CPG with " Isolated" 


=> 


UPDATE with the attribute line "a=sendonly" or 
"a=inactive" for the offered media stream 



0 
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S<3all stated 




fa; ;-;■.> 

Majppingl 




before 
answer 


CPG with " Reattached " 




UPDATE with the attribute line "a=sendrecv", or 
omitted attribute line, or "a= recvonly" for the ! 
offered media stream 


Mapping: 








□ : Mapping fiom ISUP to SIP (SIP-T) only 




CPG carries the generic notification with the contents listed above. 



Ein weitergehendes Mapping von Q.734 Nachrichten ist nicht 
erforderlich, denn die Q. 734.1 Nachrichten mit den Generic 
Notification Indicator Parametern "Other pary added", "Other 
5 party isolated", "Other party reattached", "Other party 

split", "Other party disconnected" und "Conference floating" 
(siehe Q. 734.1 [07/96], Table 1-1) dienen nur zur Information 
und erfordern keine Aktivierung des inf ormierten Teilnehmers 
und das Mapping der Q.734. 2 Nachricht mit den Generic Notifi- 
10 cation Indicator Parameter "remote hold" (siehe Q.734. 2 

[07/96], Table 2-1) ist bereits in dem vorliegenden Draft- 
Standard Q. 1912. SIP definiert. 

Dem Fachmann ist klar, dass die Erfindung bei alien einschia- 
15 gigen Netzkonf igurationen, insbesondere alien Interworking 
Szenarien TDM O IP funktioniert . Weiterhin ist dem Fachmann 
klar, dass die Erfindung bei bi-direktionalen Nutzkanalen, 
d.h. mit Sendern an jedem Ende der Nutzkanale, naturlich ohne 
weiteres in beiden Ubermittlungsrichtungen zum Einsatz kommen 
20 kann. Die Erfindung kann auch angewendet werden, wenn es 

keinen ISUP, BICC zwischen den PSTN Teilnehmern (ISDN, Analo- 
ger Teilnehmer oder auch Mobilfunk Teilnehmer) und dem SIP 
bzw. SIP-T Teilnehmern gibt. Das oben genannte Verfahren 
wiirde dann ublicherweise innerhalb von Vermittlungsstellen 
25 zum Ablauf kommen. Das Interworking von NGN (Next Generation 
Network) Teilnehmern wie VoDSL (Voice over Digital Subscriber 
Line), H323, etc... mit SIP bzw. SIP-T wird damit ebenfalls 
moglich. 

30 Abschliefiend sei darauf hingewiesen, dass die Beschreibung 

der fur die Erfindung relevanten Komponenten des Kommunikati- 



WO 2005/027487 



PCT/EP2004/052031 



21 

onsnetzes grundsiitzlich nicht einschrankend zu verstehen ist. 
Fur einen einschiagigen Fachmann ist insbesondere offensicht- 
lich, dass Begriffe wie Client, Server, Gateway, Controller, 
etc... funktional und nicht physikalisch zu verstehen sind. 
5 Alle Funktionseinheiten konnen insbesondere teilweise oder 
vollstandig in Software / Computerprogrammprodukten P 
und/oder uber mehrere physikalische Einrichtungen verteilt 
realisiert werden. 
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Patentanspriiche 

1. Verfahren zum Interworking zwischen Protokollen, mit 

5 - einer Verbindung (CALL a /b) zwischen einem ersten Teilnehmer 
(A) und einem zweiten Teilnehmer (B) , umfassend zumindest 
einen Nutzkanal (TDM A/B , RTP/RTCP a /b) / der zumindest an ei- 
nem Ende einen Sender aufweist, 

- einem Leistungsmerkmal (3PTY/CONF) , das wahrend seiner 
10 Durchfuhrung eine zeitweise Auftrennung des Nutzkanals 

vorsieht, 

- einem ersten Protokoll (ISUP) zur Steuerung des ersten 
Teilnehmers, 

- einem zweiten Protokoll (SIP) zur Steuerung des zweiten 

15 Teilnehmers, gem&fi dem die Auftrennung dezentral durch De- 

aktivierung der Sender bewirkt wird / 
mit folgenden Schritten: 

- Konfiguration der Verbindungen im Rahmen der Durchfuhrung 
des Leistungsmerkmals/ 

20 - Mitteilung der Konfiguration an betroffene Teilnehmer, 

- Interworking der Mitteilung auf das zweite Protokoll der- 
jenigen Teilnehmer, der en Sender wahrend der Durchfuhrung 
des Leistungsmerkmals deaktiviert wurde, sofern die Art 
der Konfiguration eine Aktivierung der Sender erforderlich 

25 macht, 

- Aktivierung dieser Sender. 

2. Verfahren nach Anspruch 1, 

bei dem das Leistungsmerkmal als Konferenz - insbesondere als 
30 gro&e Konferenz (CONF) entsprechend dem ITU-T Standard 

Q. 734.1 oder als kleine Konferenz (3PTY) entsprechend dem 
ITU-T Standard Q.734.2, bei denen die Auftrennung gemafi dem 
ersten Protokoll durch Unterbrechung des Nutzkanals in einem 
zentralen Obermittlungsknoten bewirkt wird - ausgebildet ist. 



35 
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3. Verfahren nach dem vorstehenden Anspruch, 

bei dem die Deaktivierung infolge einer Integration einer 
Verbindung in eine Konferenz oder infolge einer Isolierung 
einer Verbindung aus einer Konferenz erfolgt. 

5 

4. Verfahren nach einem der vorstehenden Anspriiche, 

bei dem das Interworking nur dann durchgefiihrt wird f wenn der 
Sender noch deaktiviert ist. 

10 5. Verfahren nach einem der vorstehenden Anspriiche, 

bei dem das Interworking fur den Fall, dass das erste Proto- 
koll (ISUP) gemafi einem der ITU-T Standards Q. 734.1 oder 
Q.734. 2 und das zweite Protokoll (SIP) als SIP-Protokoll 
entsprechend einem der IETF Standards RFC2543, RFC2543bis0x, 

15 RFC3261 Oder RFC3372 ausgebildet ist, wie folgt bewirkt wird: 

- Jede Q.734 Mitteilung Call Progress (CPG) mit einem Gene- 
ric Notification Indicator Parameter "Conference establis- 
hed" wird auf eine SIP Nachricht mit einer Attributzeile 
"a=sendrecv" oder "a=recvonly" oder eine SIP Nachricht oh- 

20 ne diese Attributzeile gemappt, wenn zuvor eine SIP Nach- 
richt mit Attributzeile "a=sendonly" oder "a^inactive" ge- 
sendet worden ist, 

- Jede Q.734 Mitteilung Call Progress (CPG) mit einem Gene- 
ric Notification Indicator Parameter "Conference discon- 

25 nected" wird auf eine SIP Nachricht mit einer Attributzei- 
le "a=sendrecv" oder "a=recvonly" oder eine SIP Nachricht 
ohne diese Attributzeile gemappt, wenn zuvor eine SIP 
Nachricht mit Attributzeile "a=sendonly" oder "a=inactive" 
gesendet worden ist, 

30 - Jede Q.734 Mitteilung Call Progress (CPG) mit einem Gene- 
ric Notification Indicator Parameter "Isolated" wird auf 
eine SIP Nachricht mit einer Attributzeile "a=sendonly" 
oder "a=inactive" gemappt, 
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- Jede Q.734 Mitteilung Call Progress (CPG) mit einem Gene- 
ric Notification Indicator Parameter "Reattached" wird auf 
eine SIP Nachricht mit einer Attributzeile "a=sendrecv" 
oder "a=recvonly" oder eine SIP Nachricht ohne diese Att- 
5 ributzeile gemappt. 

6. Verfahren nach dem vorstehenden Anspruch, 

bei dem die SIP Nachricht im Zustand "Answered" des zugehori- 
gen Teilnehmers als INVITE und im Zustand "before answer" als 
10 UPDATE ausgebildet ist. 

7. Verfahren nach einem der beiden vorstehenden Anspruche, 
bei dem das Interworking nur dann durchgefiihrt wird, wenn 
nach dem Senden einer SIP Nachricht mit einer Attributzeile 

15 "a=sendonly" oder "a=inactive" keine SIP Nachricht mit einer 
Attributzeile "a=sendrecv" oder "a=recvonly" bzw. keine SIP 
Nachricht ohne diese Attributzeile gesendet wofden ist. 

8. Computerprogrammprodukt (P) , umfassend Sof twarecodeab- 

20 schnitte, mit denen ein Verfahren nach einem der vorstehenden 
Verfahrensanspriiche durch zumindest einen Prozessor ausge- 
fOhrt wird. 

9. Vorrichtung - insbesondere Connection Controller Einrich- 
25 tung (MGC) - umfassend Mittel zur Durchfuhrung eines Verfah- 

rens nach einem der vorstehenden Verfahrensanspriiche. 

10. Anordnung - insbesondere paketorientiertes, integriertes 
Multimedianetz (IN) oder hybr ides Netz (IN, PSTN) - umfassend 

30 Computerprogrammprodukte und/ oder Vorrichtungen zur Durchfuh- 
rung eines Verfahrens nach einem der vorstehenden Verfahrens- 
anspriiche. 
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